fix(fe): restrict contest pages to contest admin and manager - #3821

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

Walkthrough

The contest layout fetches contest roles and renders its children only for a matching Admin or Manager role. Otherwise, it renders a component that redirects to /admin/contest and displays an access-denied error toast.

Changes

Contest access

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Sequence Diagram(s)

sequenceDiagram
  participant Layout as Contest layout
  participant Roles as contest/role
  participant Denied as ContestAccessDenied
  participant Router
  participant Toast as Error toast
  Layout->>Roles: Fetch contest roles
  Roles-->>Layout: Return roles or fetch error
  Layout->>Denied: Render when no matching Admin or Manager role exists
  Denied->>Router: Replace route with /admin/contest
  Denied->>Toast: Show access-denied error after 100 ms

Security Blast Radius

• inferred — The retained stale-layout path concerns a previously authorized user's contest UI and already-fetched information, including an invitation code. The inspected current-role guard limits subsequent protected requests after revocation. Separately, the inherited null-identity role endpoint can expose contestId and role metadata across userContest rows. Neither path establishes newly gained mutation authority, infrastructure access or broader data-store privileges from this PR.

Security Findings and Attack Paths

• inferred — The retained, reportable medium-severity authorization finding describes role removal followed by client navigation that reuses an authorized layout and already-loaded content. The new gate checks roles only when its server layout executes; force-dynamic does not itself provide explicit invalidation of mounted client state. Base/head comparison shows that the cached-content mechanism already existed under a route with no contest-specific parent gate. The PR does not demonstrably introduce or worsen that exposure, although its new admission check does not resolve continuous revocation.

Trust Boundaries and Controls

• inferred — The actual REST producer has an inherited identity gap: authentication failure on a public request can return a null user, and the controller then passes undefined userId into findMany. With the inspected Prisma configuration lacking strict undefined checking, the filter can be omitted, allowing other users' role rows to satisfy the new layout's contest-and-role test. This is a successful-response path, so the layout's exception handling does not deny it. The endpoint and the outer admin layout's existing use of it predate the PR; expanded effective access was not established.

Resilience and Maintainability Implications

• observed — Role removal and role updates mutate the authoritative userContest records, so subsequent role-list and ordinary-user guard reads observe those writes. The new layout adds no corresponding invalidation of already-rendered authorization state. Full server re-entry obtains current roles; exact interruption, concurrency and client remount behavior remain unverified.

Hardening Proposals

• proposed — Require a valid authenticated identity for role-list responses, or explicitly return no roles when identity is missing. Reject undefined identity filters before database access so successful responses cannot borrow another user's membership.
• proposed — Define permission and identity transitions explicitly: revalidate route admission and clear sensitive client state when membership or session identity changes. Preserve per-operation backend enforcement and verify revocation through repeated navigation, interruption and recovery.

❌ Failed checks (1 warning)

• X
• Mastodon
• Reddit
• LinkedIn